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ABSTRACT 


There is a need to understand cycles associated with software upgrades 
as they affect people, organizations and the software industry. This thesis 
intends to explore the moderating factors of these three distinct and disjointed 
cycles and propose courses of action towards mitigating various issues and 
problems inherent in the software upgrade process. 

This thesis will acknowledge that three related but disjointed cycles are 
common in many software upgrade ventures in today’s organizations: 

d. End-user characteristics in adapting to new software 

e. Organizational ability to adopt new software 

f. The software industry’s motivation and processes in introducing new 
software 

Realizing the importance of these related cycles involves developing an 
understanding of several aspects we research in this study. First, awareness in 
understanding why users adopt new software and the demographic factors 
involved, such as gender, age and experience are considered. Second, we 
present how organizations integrate new software by exploring factors such as 
cost, time, reliability and benefit analysis. Last, we provide evidence supporting 
motivating forces and factors behind software introduction rates within the 
software industry. These important aspects together culminate in cyclical 
phenomenon managers and executives need to be aware of, as implementing 
new software upgrades have become an inevitable undertaking in most of 
today’s organizations. 
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I. INTRODUCTION 


A. BACKGROUND 

Fifteen years ago most people didn’t use software in their daily lives. 
Affordable computing didn’t exist, and for those few people who did use 
computers as part of their daily routine, did so from expensive terminals 
operating proprietary software and hardware configurations, which usually 
required extensive training and ongoing support (Platt 2007). 

That has changed completely. Almost overnight, in societal terms, 
cheaper hardware, software and networked computers have paved a path for the 
information superhighway. People use computers to pay creditors on-line using 
high speed internet access, send pictures, post web sites, stream video, chat, 
and a myriad of other processes. The modern business uses computers and 
software as a tool for gaining an edge over their competitors by bringing products 
and services to their customers in more convenient and timely ways. An 
explosion of information, data, resources and trade has been made possible 
through the globally interconnected world we know today. 

Many people today find themselves using technology whether they want to 
or not. Computers and software present endless opportunities for the wide 
variety of users including the entrepreneur, CEO’s, artists and young gamers 
everywhere. On the other hand, some users find themselves getting bogged 
down in the never-ending barrage of new technology implementations in their 
workplace. For example, many of these people might realize that their 
organization’s new software may provide an advantage over their competitor, or 
may simply provide a new aspect of convenience for their customers. All too 
often, however, changing to new software may be anything but advantageous or 
convenient for those involved in the software implementation and adoption. In 
fact, as technology and affordability of computer systems increase and become 
more popular for people and their organizations, the associated software choices 
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too become more plentiful and complex. People trying to keep up with new 
advances in software might be a little overwhelmed when faced with new and 
improved user interfaces because it takes time to learn and adapt to the new way 
of doing business. In the workplace, people are expected to use many different 
kinds of software to carry out business as usual. In large organizations hundreds 
of software applications and packages are used to manage products, services 
and human resources and as time passes, new iterations and upgrades to these 
applications become available. Software manufacturers push their new software 
products based on speed, capabilities, ease of use and any number of other 
qualities that support their claims of a better version than the last one, and in 
many cases their claims are true. After all, this is the fundamental expectation of 
what we call “upgrades”. 

We’ve come to understand that new software upgrades are supposed to 
make life easier in the workplace. A new upgrade might enable us to get work 
done safer, faster, and easier or in some way provide better aesthetics, which is 
perceived to be more professional. In any case, what we want to believe is that 
upgrading software will improve the business process, increase competitive 
advantage and provide better customer service. Unfortunately, it’s not as simple 
as just purchasing, installing an upgrade and receiving immediate improvements. 

“We live our lives in a sea of software, but most users have no idea how 
software is developed or why it works the way it does. We only know that we 
don’t like it very much.” (Platt 2007). In addition, most users don’t know how to 
use software to it’s full potential. In many cases, software manufacturers release 
their software products for sale knowing significant flaws and bugs exist but in 
many cases, tight deadlines, budgets constraints or confidence their new 
software will sell anyway, entices premature releases. The release of buggy 
software only creates more frustration and delays for the end user contributing to 
resistance of future software changes in the workplace. By and large, users tend 
to develop their own cycle when implementing new software, but moderating 
factors often include training, ones resistance to the change, and the amount of 

time it takes him or her to become comfortable and productive with the software. 
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Adopting new software within organizations has cycles as well, although 
for different reasons than end user cycles. An organization’s motives for 
changing, or not changing, to new software vary from such things as necessity, 
opportunity and affordability. For instance, an organization may upgrade to new 
software because not doing so would interfere with its user’s ability to accomplish 
important business functions. Additionally, an organization might adopt new 
software to capitalize on an opportunity, which may lead to an advantage over its 
competitors. Sometimes organizations simply change to new software because 
they have the money to spend on what they perceive as a new and improved 
version. No matter the reason, organizations have cycles in adopting new 
software, and those cycles may be quite different from the user’s cycle. 

Software manufacturers also have cycles and producing and selling new 
software as quickly as possible for the sake of profit seems to be the name of the 
game in many cases. In fact, new technologies are introduced to the market at a 
pace that makes it difficult for organizations and their users to keep up with. The 
software industry’s strategies rely heavily on reducing their product’s time to 
market. Often times, quality and proper documentation take a back seat to 
product diversity and approaching release deadlines (Carmel, E. 1995). 

Upgrades in software are inevitable and with more and more businesses 
adapting to computing technology in daily operations, new software has become 
an essential part of an organization’s IT portfolio. According to a report by I DC, 
America’s applications software market was $54.8 billion in 2005 and is projected 
to increase to $76.5 billion by 2010 (IDC 2006). Today, many organizations 
upgrade by purchasing and implementing packaged software. This is 
commercial software that is available for sale off the shelf, like MS Windows 
operating systems, office suites and so on. There are many kinds of software 
packages, ranging from end user applications to database management systems 
to telecommunication protocols. Additionally, outsourcing IT is becoming more 
and more popular as well as implementing Enterprise Resource Planning (ERP) 
solutions. Outsourcing and ERP solution are aimed at hiring outside organization 

to manage IT lifecycles, support, and upgrades. 
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As software companies respond to business demands and add new 
features to make software perform better, new versions of software are being 
released into the market in frequent succession (Paine 2000). In fact, between 
the years 1995 and 2001, Microsoft launched 6 Desktop operating systems as 
shown in Figure 1. 
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Figure 1. Windows Software Cycle 
From Windows History 

http://www.microsoft.com/windows/WinHistoryProGraphic.mspx Last 

accessed May 2008 . 


To managers everywhere, it is a constant question of whether the current 
version of software is “obsolete,” or outdated, and warrants an upgrade. The 
decision to upgrade is often times not in the hands of the end user or the 
organization. 
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Unless they are licensed to have total code autonomy, an upgrade can be just a 
matter of timing (Paine 2000). The question then becomes: when should they 
upgrade? 

So how do managers within organizations determine if it’s time to 
upgrade? If managers felt for example, that Windows XP is still sufficient for their 
current needs, should they migrate to the latest version - Windows Vista? What 
are the factors that influence their decision? What implications does it have for 
their organization in terms of business operating procedures, policies and 
doctrine? Will the manufacturer still support the older version of software that the 
business is running now? These are some of the questions that organizations 
ask every time a new version of software package emerges from the market. 
Deciding how and when to upgrade are not the only problems facing IS 
management, however, upgrades usually carry unexpected consequences as will 
be addressed later in the organization adoption cycle. 

1. Known Upgrade Problems 

People often associate upgrades with better quality. Organizations 
usually upgrade to the latest version of software to attain efficiency and improved 
functionality that the current software lacks (Paine 2000). Most people would 
assume that simply updating or upgrading their software means they would reap 
the benefits of more useful features and functions, which presumably increases 
users’ productivity. Ideally, a software upgrade will fix existing bugs and enhance 
operability. Unfortunately, many software upgrades have many problems upon 
first execution because they rarely work properly or as initially intended in the 
beginning. Sometimes this is due to legacy software incompatibility buggy 
software, or lack of knowledge. 

A 2002 study commissioned by the National Institute of Standards and 
Technology found software bugs cost the U.S. economy about $59.5 billion 
annually. The same study found that improving testing could have mitigated 
more than a third of that cost -about $22.2 billion. 
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Although upgrades don’t cause headaches for everyone everyday, routine 
upgrades often cause unexpected problems. Currently many people and 
organizations are upgrading to the Windows Vista (WV), an operating system 
created by Microsoft as an upgrade to Windows XP. Windows Vista was 
released in several stages; on November 30, 2006 it was released to business 
customers, computer hardware and software manufactures, and to the rest of the 
world on January 30, 2007. What people are finding is that Vista’s Aero interface 
requires a specific set of video capability including: a DirectX 9 (or better) 3D 
graphics processor that supports 32 bits per pixel, and Pixel Shader 2.0. It must 
also be offered with a WDDM (Windows Vista Display Driver Model) driver. 
Additionally, the following hardware recommendations are common for a Vista 
upgrade: Intel (or comparable AMD) 1,8GHz (minimum) Pentium 4 CPU, 2GB of 
RAM, 80GB hard drive (60GB if you're clean installing) and a DVD drive. What 
this means for some people and organizations with outdated equipment is that a 
simple upgrade either won’t work properly on their existing machines or they are 
faced with upgrading their hardware along with the software. Many think an 
upgrade is just a simple task of installing the next version of software, overlaying 
new code over old code, upgrading to new software can lead to many problems 
(Paine 2000). 

As mentioned on the previous page, one of the problems inherent in 
packaged software is that known bugs haven’t been ironed out before release. It 
has been found that one out of seven software firms deliver code without 
adequate prior testing (Minasi and Garde 1999). Another cause for upgrade 
problems is vendors’, and their modifications of previous design logic. This often 
times renders the new version incompatible with the old. For example, the file 
format has been changed in the new Microsoft Office 2007 suite from previous 
versions. For older versions of Office to read the new 2007 file format, you must 
install the Microsoft Office Compatibility Pack for 2007 Office Word, Excel and 
PowerPoint file formats. 

Frequent upgrades can be frustrating and troublesome to programmers, 

users and administrators when the upgrade produces or results in down-time, or 

6 



complications. For administrators, many man-hours are spent on correcting the 
faulty code or other quality user interface problems that come with an upgrade. 
Most organizations have spent at least some portion of their IT budget on test 
bed equipment, which simulates their live environment in some way. From 
exposing upgrades, patches and service packs to the test bed, IT professionals 
can catch bugs before they launch the new products in the real environment. 
Organizations that choose not to spend resources on testing, or can’t afford to 
spend limited resources on testing facilities and equipment, assume great risk. 
Sometimes this risk is at the expense of their users and the users’ productivity 
levels. For the unlucky, the upgrade version that was supposed to bring 
improvements inevitably slows down productivity when the software doesn’t work 
properly after installation. 

These problems in upgrading software can have a profound effect on the 
cycles associated with the new changes people and organizations are willing to 
make. Software is expensive especially where large organizations are 
concerned. Managers are therefore reluctant to purchase software if it’s going to 
cause them problems from the start, if it’s not compatible with older versions of 
the same software, or if they need to purchase new hardware to accommodate 
upgrades. For example, the British Educational Communications and 
Technology Agency (BECTA), responsible for advising British schools and 
colleges on their IT use, conducted a report on Microsoft Vista and Office 2007. 
Their results concluded that British schools should not make the upgrade (Becta 
2008). The BECTA report recommended that British schools should not 
introduce the software piecemeal alongside other versions of Windows, or 
upgrade older machines. 

“We have not had sight of any evidence to support the argument that the 
costs of upgrading to Vista in educational establishment would be offset by 
appropriate benefit,” it said. 

About Office 2007 it remarked, “There remains no compelling case for 
deployment.” 
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BECTA warned schools that do choose to upgrade to Office 2007 should 
avoid Microsoft’s OOXML (Office Open XML) document format because of 
concerns about compatibility between different applications, even though 
interoperability is one of the benefits Microsoft claims for the format. 

We assume that reports like BECTA’s affect people’s motivation and 
organizational time intervals associated with software upgrade cycles and we 
intend to shed some light on why we think this is true in the next few chapters. 

2. Importance of Upgrade Issues 

Now, we will show why this area is worthy of further study. First, it is 
unknown how carefully organizations are paying attention to software upgrade 
problems. Until the problems are identified and studied it seems that no viable 
action will emerge toward solving the issues. Second, software upgrades are a 
continuous problem because once software is installed; users and organizations 
will very likely want an upgrade eventually unless it is completely abandoned. 
Third, the actual impacts of software upgrades are largely unknown. Anecdotal 
evidence suggests that the upgrade process is problematic, however, to date, we 
have been unsuccessful in finding evidence that attempts to fully understand the 
problems. Fourth, it is unknown how organizational cycles of upgrades are 
coping with the problems or preparing them for the next upgrade. Fifth, If the 
phenomenon of software upgrade cycles can be understood, then better 
strategies can be developed which might help users adapt easier, organizations 
adopt more effectively and software manufacturers to develop and deploy more 
efficiently. 

Overall, this is an area that in our opinion has largely escaped academic 
attention. Most investigations of the problems described above are gathered 
from trade journals while no empirical research has been found that researches 
these issues. Traditionally, academic research has focused primarily on studies 
related to information systems implementation (Lucas, Walton et al. 1988; Thong, 
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Yap et al. 1996) and no studies were found to have concentrated solely on 
software upgrade cycles among people, organizations and the software industry. 

One possible reason for this lack of academic attention could be that it has 
been overlooked as a trivial problem. If the software already exists and an 
upgrade is merely providing subtle changes, then user acceptance or technology 
fit may not be as big of an issue. These kinds of upgrades may not incur as 
much business process change or adaptation time as completely new software 
suite integration would. Still, as the problems presented in the previous chapters 
indicate, unanticipated problems do occur when new software is installed. 

Implementing new software upgrades warrant further research. The 
objective of this study is to investigate the cyclical phenomenon associated with 
new software upgrades from three standpoints: people’s ability to adapt to new 
software, organizations ability to adopt and install new software, and the software 
industry’s desires to introduce new software. These aspects will be compared to 
understand and identify possible benefits and value among re-occurring cycles in 
software implementation within organizations. 

The following research questions are posed to investigate these 
phenomena. 

1. Primary: How are the organizational, personal and software 
industry’s development and adoption cycles related? 

2. Secondary 1: How might synchronization of cycles benefit adoption 
of software? 

3. Secondary 2: Is technology, with respect to advances in software, 
moving at a pace that is too fast for large organizations like the 
DoD to keep up with? 
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II. METHODOLOGY 


A. QUALITATIVE APPROACH 

To investigate the research questions, a qualitative approach was deemed 
most appropriate. First, unlike some phenomena that can be simulated and 
studied in a laboratory environment, software upgrades and how they affect 
users, organizations and the software industry cannot be studied in a similar 
environment. The phenomenon our research is based upon can be studied in 
organizations where software upgrades were implemented, where people 
adapted to upgrades and where the software industry was able to introduce 
upgrades. According to Denzin and Lincoln (1998), 

“Qualitative research is multi-method in focus, involving an interpretive, 
naturalistic approach to its subject matter. This means that qualitative 
researchers study things in their natural settings, attempting to make sense of, or 
interpret, phenomena in terms of the meanings people bring to them.” 

Qualitative research also has four characteristics according to Lee, Mitchel 
et al. (1999) It occurs in a natural setting, it derives data from the perspective of 
participants, it can be flexibly changed to accommodate the demands the 
research situation, and last, it does not have standard instrumentation, which 
makes notions of control, reliability and validity difficult to obtain. 

The objective of this research is to study software upgrades where they 
occur from three perspectives: 

The organizational perspective: Where software upgrade adoption cycles 
are disjointed from user cycles and software production cycles. 

The user perspective: Where software upgrade adaptation cycles are 
disjointed from their organization’s cycle as well as software production cycles. 
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The software industry’s perspective: Where production cycles are 
disjointed from average organizational and user cycles. 

Additional areas of interest will be researched in an attempt to provide at 
least partial answers our secondary research questions mentioned in the last 
chapter. It is assumed that as technology allows software to progress and be 
produced in faster cycles, and that organizations and their users are less likely to 
be capable of making use of these rapidly evolving software benefits. 
Additionally, we believe that as these cycles increase in speed and complexity, 
those who are unable or incapable of evolving with new software trends will be 
more likely to lose vital competitive advantages. 

B. RESEARCH DESIGN 

From a research standpoint, our design is simplistic which allows for a 
loose structure. A research design that is tight in structure is usually 
characteristic of one that also has many pre-determined guidelines. 
Consequently, our first question was to ask our selves how tight the preliminary 
design should be and how much planning should go into it. 

Some factors are important in trying to answer this question. First, it 
depends on the nature of the research involved: whether the research is 
exploring and understudied phenomenon, to induce a social theory, to confirm 
well-defined constructs, or to investigate a hypothesis. Traditionally, a loose 
structure in research design is usually common with exploratory, inductive 
research whereas a tightly structured research design is usually synonymous 
with confirmatory, theory testing type of research. Miles and Huberman (1994) 
claim: 

Much qualitative research lies between these two extremes. 

Something is known conceptually about the phenomena, but not 
enough to house a theory. The researcher has an idea of the parts 
of the phenomenon that are not well understood and knows where 
to look for these things - in which settings, among which actors. 

And the researcher usually has some initial ideas about how to 
gather the information. At the outset, then, we usually have at least 
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a rudimentary conceptual framework, a set of general research 
questions, some notion about sampling, and some initial data- 
gathering devices, (p. 17) 

C. CONCEPTUAL DESIGN 

“A conceptual framework explains, either graphically or in narrative form, 
the main things to be studied” (Miles and Huberman 1994). The “main things” 
mentioned here refer to the key elements of the research being conducted and 
the relationships among them. In this case, our conceptual framework does not 
represent a theoretical model awaiting confirmation. Instead, it is a map of those 
elements that are to be explored in this study. The preliminary conceptual 
framework is presented in Figure 2 below. 


Adoption Cycle Adaptation Cycle 



Figure 2. Software Upgrade Cycle 
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1. Description of the Diagram 


There are four circles in Figure 2, Organization, Users, Software Industry 
and Software Upgrade Cycle. The large circle in the middle of the diagram 
represents the main topic (Software Upgrade Cycle) of our study and the smaller 
circles encompassing it represent the basis of our research in examining the 
main topic. Each smaller circle is labeled, on its outer edge, with the name of the 
cycle associated with the area it focuses on. For example, the User circle is an 
area of proposed study and it is labeled with Adaptation Cycle, which represents 
the problem or issue that we assume effects the user in the most meaningful 
way. 

Here, our ideas are represented in the form of circles with arrows because we 
want to display our interpretation that software upgrade cycles are a process model 
rather than a causal model. The smaller circles are also touching the larger circle, 
which is intended to represent the idea that organizations, users and the software 
industry are very much linked to the software upgrade cycle process. We suspect 
also that the internal and external influences that drive the organizations, users and 
software industry, also drive the software upgrade cycle. From this idea, we can 
“see” the smaller circles grinding away at the larger circle and spinning it. This 
alludes to the fact that as the cycles of the organizations, users and software 
industry increase in speed, so will the entire software upgrade cycle process speed 
up. 

As one can imagine, the circles spinning in an orderly or “gear-driven” 
fashion, it is important to recognize that we don’t believe this process is actually 
orderly. These cycles are in fact disjointed and act separately as internal and 
external forces affect them. Our figure was purposely drawn with circles instead of 
gears to highlight the fact that slippage occurs and the circles can spin at very 
different speeds in comparison with the other circles. This represents the idea that, 
for instance, the software industry cycle may be churning at a faster speed than the 
organization cycle. This simply indicates that the rate at which software is being 
introduced is outpacing the rate at which an organization is able to adopt that 
software. 
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III. USERS, ORGANIZATIONS AND SOFTWARE INDUSTRY 


A. USER ADAPTATION CYCLES 

Recent research focusing on users’ adaptation to new technology is 
predominantly studied using two commonly used theories, the Unified Theory of 
Acceptance and Use of Technology (UTAUT) and the Technology Acceptance 
Model (TAM). We will first describe these two theories and reveal assumptions 
predicated on strong behavioral intentions, usage behaviors, perceived 
usefulness and perceived ease of use. We will then reference the UTAUT in 
attempting to explain adaptation behaviors of users in organizations through 
exploring two case studies. The Technology Acceptance Model has been a 
popular method in researching and realizing the importance of end-user 
acceptance, a key success factor of Enterprise Resource Planning (ERP) 
implementations. Criticism against applying the TAM to examine ERP 
acceptance is that the use of an ERP is mandatory for an organizations end 
users, while an implicit assumption of TAM is that users of the information 
systems have some level of choice with regard to the extent that they use the 
technology. For this reason, we will focus on using case studies that use the 
UTAUT model instead of the TAM. Researchers have found that using TAM to 
evaluate acceptance of new technology provides limited explanation of end- 
users’ behavior, attitudes and perceptions towards the system and that the 
results of studies based on the TAM may provide misleading recommendations 
for organizations (Brown et al. 2002). 

1. Exploring the UTAUT Model 

The first case study we will focus on is called “User Acceptance of 
Information Technology: Toward a Unified View” by Venkatesh, Morris, Davis, B., 
and Davis, F. This case study reviews and consolidates constructs and 
extensions from eight prominent models of usage behavior to formulate the 
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Unified Theory of Acceptance and Use of Technology model. The study used 
data from four organizations over a six-month period, among individuals being 
introduced to a new technology in the workplace. Samples were gathered for 
heterogeneity across technologies, organizations, industries, business functions 
and nature of use (voluntary vs. mandatory). The approach used by Venkatesh 
et al. in gathering and validating data was consistent with prior training and 
individual acceptance research where individual reactions to a new technology 
were studied (e.g., Davis et al. 1989; Olfman and Manviwalla 1994; Venkatesh 
and Davis 2000). The methodology for acquiring the data came from a pre¬ 
tested questionnaire containing items measuring constructs from the eight 
models at three different points in time: post-training, one month after 
implementation, and three months after implementation. Table 1 summarizes the 
key characteristics of the organizational settings. 


Industry 

Functional Area 

Sample Size 

System Description 

Voluntary Use 

Entertainment 

Product Development 

54 

Online meeting manager 
that could be used to 
conduct web-enabled 
video or audio 
conferences in lieu of 
face-to-face or traditional 
phone conferences 

Telecomm 

Services 

Sales 

65 

Database application that 
could be used to access 
industry standards for 
particular products in lieu 
of other resources (e.g., 
technical manuals, Web 
sites 

Mandatory Use 

Banking 

Business Account 
Management 

58 

Portfolio analyzer that 
analysts were required to 
use in evaluating existing 
and potential accounts 

Public 

Administration 

Accounting 

38 

Proprietary accounting 
systems on a PC platform 
that accountants were 
required to use for 
organizational 
bookkeeping 


Table 1. Key data characteristics 
From (Venkatesh, V. et al. 2003) 
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In using UTAUT and TAM, we expect to be able to shed further light on 
how and why users in an organization adapt to new software. The case studies 
will confirm that the theories provide a useful tool for managers needing to 
assess the likelihood of success for new technology introductions and help them 
understand the drivers of acceptance within their organizations. This ultimately 
gives managers an advantage towards proactively designing interventions 
(including training, marketing, etc.) targeted at populations of users that may be 
less inclined to adopt and use new systems. 

First, it is important to understand the principles of the theories described 
above in order to provide a foundation in understanding users’ adaptation of new 
software. We will begin by exploring the Unified Theory of Acceptance and Use 
of Technology. The UTAUT aims to explain user intentions to use an Information 
Systems (IS) and subsequent usage behavior. The theory holds that four key 
constructs (performance expectancy, effort expectancy, social influence, and 
facilitating conditions) are direct determinants of usage intention and behavior 
(Venkatesh et al., 2003). Gender, age, experience, and voluntariness of use are 
posited to mediate the impact of the four key constructs on usage intention and 
behavior (Venkatesh et. al., 2003). The theory was developed through a review 
and consolidation of the constructs of eight models that earlier research had 
employed to explain IS usage behavior (theory of reasoned action, technology 
acceptance model, motivational model, theory of planned behavior, a combined 
theory of planned behavior/technology acceptance model, model of PC 
utilization, innovation diffusion theory, and social cognitive theory). Subsequent 
validation of UTAUT in similar studies found it to account for 70% of the variance 
in usage intention (Venkatesh et. al., 2003). 

Of the eight models listed above, Venkatesh et al., theorizes that four of 

the constructs play a significant role as direct determinants of user acceptance 

behavior. These are performance expectancy, effort expectancy, social influence 

and facilitating conditions. Each of the determinants is impacted by the role of 

their key moderators, which are gender, age, voluntariness and experience. 

Exploring these determinants and their key moderators reveal theoretical 
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justification in explaining the phenomena about how and why users in an 
organization adapt to new software. Figure 3 shows the Venkatesh et al. 
research model, which depicts the four determinants and their four key 
moderators. Note that the model shows these constructs as directly influencing a 
user’s behavioral intention and use behavior. 



Figure 3. UTAUT Research Model 
From (Venkatesh, V. et al. 2003) 


The four key constructs (performance expectancy, effort expectancy, 
social influence and facilitating conditions) according to Vanketesh et al., are 
used to explain significant direct determinants of user acceptance and usage 
behavior. In the remainder of this section we define each of the determinants, 
specify the role of the key moderators (gender, age, voluntariness, and 
experience), and provide the theoretical justification relating to user adaptations 
to new software and subsequent usage behavior. 
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a. Performance Expectancy 


Performance expectancy is defined as the degree to which an 
individual believes that using the system will help him or her to attain gains in job 
performance. The performance expectancy construct was found to be the 
strongest predictor of intention and remained a significant indicator at all points of 
measurement in both voluntary and mandatory settings within the Venkatesh et 
al. case study. Five constructs pertaining to performance expectancy were 
consolidated from the eight previously mentioned models, they are: 

• perceived usefulness 

• extrinsic motivation 

• job-fit 

• relative advantage 

• outcome expectation 

Table 2 describes each of these root constructs and describes the 
scales used for the study. Within each scale is a list of items that correspond to 
perceptions on the performance expectancy realized by each individual user. 
These items are of particular interest as they relate to explanations regarding 
usage behavior and intent to use the new technology. 
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Performance Expectancy: Root Constructs, Definitions and Scales 

Perceived Usefulness 

The degree to which a person 
believes that using a particular 
system would enhance his or her 
job performance 

1. Using the systems in my job would enable me to 
accomplish tasks more quickly. 

2. Using the system would improve my job 
performance. 

3. Using the system in my job would increase my 
productivity. 

4. Using the system would enhance my effectiveness 
on the job 

5. Using the system would make it easier to do my 
job 

6. 1 would find the system useful in my job. 

Extrinsic Motivation 

The perception that users will want 
to perform an activity because it is 
perceived to be instrumental in 
achieving valued outcomes that are 
distinct from the activity itself, such 
as improved job performance, pay, 
or promotions 

Extrinsic motivation is operationalized using the same 
items as perceived usefulness (items 1 through 6 
above) 

Job-fit 

How the capabilities of a system 
enhance an individual’s job 
performance 

1. Use of the system will have no effect on the 
performance of my job. 

2. Use of the system can decrease the time needed 
for my important job responsibilities 

3. Use of the system can significantly increase the 
quality of output on my job 

4. Use of the system can increase the effectiveness 
of performing job tasks 

5. Use can increase the quantity of output for the 
same amount of effort 

6. Considering al tasks, the general extent to which 
use of the system could assist on the job. 

(different scale used for this item) 

Relative advantage 

The degree to which using an 
innovation is perceived as being 
better than using its precursor 

1. Using the system enables me to accomplish tasks 
more quickly 

2. Using the system improves the quality of the work 

1 do. 

3. Using the system makes it easier to do my job 

4. Using the system enhances my effectiveness on 
the job 

5. Using the system increases my productivity 

Outcome expectations 

Outcome expectations relate to the 
consequences of the behavior 

If 1 use the system... 

1. 1 will increase my effectiveness on the job 

2. 1 will spend less time on routine job tasks 

3. 1 will increase the quality of output of my job 

4. 1 will increase the quantity of output for the same 
amount of work 

5. My coworkers will perceive me as competent 

6. 1 will increase my chances of obtaining a 
promotion 

7. 1 will increase my chances of getting a raise 


Table 2. Performance expectancy: Root Constructs, Definitions, and Scales 

From (Venkatesh, V. et al. 2003) 

Venkatesh et al., expected that from a theoretical standpoint, the 
relationship between performance expectancy and intention are moderated by 
gender and age. Research on gender differences have indicated that men tend 
to be more task oriented than women (Minton and Schneider 1980) and, 
therefore, performance expectancies, which mainly focus on task 
accomplishment, are likely to be especially prominent to men. Similar to gender, 
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age is theorized to play a moderating role (Venkatesh et al. 2003). Previous 
research on job related attitudes suggest that younger workers may place more 
importance on extrinsic rewards (Hall and Mansfield 1995). It is also important to 
note that studies of gender differences can be misleading without reference to 
age. A good example points towards the traditional societal gender roles where 
job related factors may change significantly (e.g., become supplanted by family- 
oriented responsibilities) for working women between the time that they enter the 
labor force and the time they reach child-rearing years. Thus, we surmise that 
gender and age both influence performance expectancy such that the effect 
tends to be stronger for men and particularly for younger women. 

b. Effort Expectancy 

Effort expectancy is defined as the degree of ease associated with 
the use of the system. The effort expectancy construct is significant in both 
voluntary and mandatory usage contexts but tends to become less significant 
over periods of extended and sustained usage. Venkatesh et al. concludes that 
the influence of effort expectancy on behavioral intention is moderated by 
gender, age and experience, such that the effect is stronger for women, 
particularly younger women, and particularly at early stages of experience. Table 
3 describes each of these root constructs and describes the scales used for the 
study. Within each scale is a list of items that correspond to perceptions on the 
effort expectancy realized by each individual user. These items are of particular 
interest as they relate to explanations regarding usage behavior and intent to use 
the new technology. 
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Effort Expectancy: Root Constructs, Definitions and Scales 

Percieved Ease of Use 

The degree to which a person 
believes that using a system would 
be free of effort 

1. Learning to operate the system would be easy 
for me. 

2. 1 would find it easy to get the system to do what 1 
want it to do. 

3. My interaction with the system would be clear 
and understandable 

4. 1 would find the system to be flexible to interact 
with 

5. It would be easy for me to become skillful at 
using the system 

6. 1 would find the system easy to use 

Complexity 

The degree to which a system is 
perceived as relatively difficult to 
understand and use 

1. Using the system takes too much time from my 
normal duties. 

2. Working with the system is so complicated, it is 
difficult to understand what is going on 

3. Using the system involves too much time doing 
mechanical operations (e.g., data input) 

4. It takes too long to learn how to use the system 
to make it worth the effort 

Ease of Use 

The degree to which using an 
innovation is perceived as being 
difficult to use 

1. My interaction with the system is clear and 
understandable 

2. 1 believe that it is easy to get the system to do 
what 1 want it to do. 

3. Overall, 1 believe that the system is easy to use. 

4. Learning to operate the system is easy for me. 


Table 3. Effort Expectancy: Root Constructs, Definitions and Scales 

From (Venkatesh, V. et al. 2003) 


Effort expectancy has been found to be more salient for women 
than for men (Venkatesh and Mooris 2000) and (Bern and Allen 1974). Similar to 
performance expectancy, gender differences are commonly driven by gender 
roles. Increased age has been found to be associated with difficulty in 
processing complex stimuli and allocating attention to information on the job, 
both of which may be necessary when using software systems (Plude and Hoyer 
1985). 


c. Social Influence 

Social influence is defined as the degree to which an individual 
perceives that important others believe he or she should use the new system. 
Each construct associated with social influence contains the explicit or implicit 
notion that the individual’s behavior is influenced by the way in which they 
believe others will view them as a result of having used the technology. Social 
influence in technology acceptance decisions is complex and subject to a wide 
range of contingent influences. Intention to use and behavior studies show that 


22 




none of the social influence constructs are significant in voluntary contexts; however, 
each becomes significant when use of a system is mandatory. Venkatesh et al. 
concludes that in mandatory settings, social influence appears to be important only 
in the early stages of individual experience with the technology, but its role erodes 
over time and eventually becomes nonsignificant with sustained usage. Social 
influence has an impact on individual behavior through three mechanisms: 
compliance, internalization, and identification. The compliance mechanism causes 
an individual to simply alter his or her intention in response to social pressure (i.e., 
the individual intends to comply with the social influence). Internalization and 
identification relate to altering an individuals belief structure and/or cause an 
individual to respond to potential social status gains. Prior research suggests that 
individuals are more likely to comply with others’ expectations when those referent 
others have the ability to reward the desired behavior or punish nonbehavior 
(Warshaw 1980). Technology acceptance studies indicate that reliance on others’ 
opinions is also significant only in mandatory settings and particularly in the early 
stages of experience, when an individual’s opinion may be relatively ill-informed or 
premature (Venkatesh and Davis 2000). Venkatesh et al., theorizes that women 
tend to be more sensitive to others’ opinions and therefore find social influence to be 
more salient when forming an intention to use new technology. Additionally, older 
workers have been found to be more likely to place increased salience on social 
influences, with the effect declining as more experience is gained. Thus, the 
influence of social influence on behavioral intention is moderated by gender, age, 
voluntariness and experience, such that the effect will be stronger in women, 
particularly older women, and particularly in mandatory settings in the earlier stages 
of experience. 

Table 4 describes each of the root constructs associated with social 
influence and describes the scales used for the study. Within each scale is a list of 
items that correspond to perceptions on the effort expectancy realized by each 
individual user. These items are of particular interest as they relate to explanations 
regarding usage behavior and intent to use the new technology. 
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Social Influence: Root Constructs, Definitions and Scales 

Subjective Norm 

The person’s perception that most people 
who are important to him think he/she 
should or should not perform the behavior 
in question 

1. People who influence my behavior think 
that 1 should use the system 

2. People who are important to me think that 

1 should use the system 

Social Factors 

The individual’s internalization of the 
reference group’s subjective culture, and 
specific interpersonal agreements that the 
individual has made with others, in specific 
social situations 

1. 1 use the system because of the 
proportion of coworkers who use the 
system 

2. The senior management of this business 
has been helpful in the use of the system 

3. My supervisor is very supportive of the 
use of the system for my job 

4. In general, the organization has 
supported the use of the system 

Image 

The degree to which use of an innovation is 
perceived to enhance one’s image or status 
in one’s social system 

1. People in my organization who use the 
system have more prestige than those 
who do not 

2. People in my organization who use the 
system have a high profile 

3. Having the system is a status symbol in 
my organization 


Table 4. Social Influence: Root Constructs, Definitions and Scales 

From (Venkatesh, V. et al. 2003) 


d. Facilitating Conditions 


Facilitating conditions are defined as the degree to which an 
individual believes that an organizational and technical infrastructure exists to 
support the use of a system. The concept is characterized by three different 
constructs: perceived behavioral control, facilitating conditions and compatibility. 
Each of these concepts includes aspects of the technological and/or 
organizational environment that are designed to remove barriers to use. Table 5 
describes each of the root constructs associated with facilitating conditions and 
describes the scales used for the study. Within each scale is a list of items that 
correspond to perceptions on the effort expectancy realized by each individual 
user. These items are of particular interest as they relate to explanations 
regarding usage behavior and intent to use the new technology. 
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Facilitatini 

g Conditions: Root Constructs, Definitions and Scales 

Perceived Behavioral Control 

Reflects perceptions of internal and 
external constraints on behavior and 
encompasses self-efficacy, resource 
facilitating conditions, and technology 
facilitating conditions 

1. 1 have control over using the system 

2. 1 have the resources necessary to use 
the system 

3. 1 have the knowledge necessary to use 
the system 

4. Given the resources, opportunities and 
knowledge it takes to use the system, it 
would be easy for me to use the system 

5. The system is not compatible with other 
systems 1 use 

Facilitating Conditions 

Objective factors in the environment that 
observers agree make an act easy to do, 
including the provision of computer 
support 

1. Guidance was available to me in the 
selection of the system 

2. Specialized instruction concerning the 
system was available to me 

3. A specific person (or group) is available 
for assistance with the system 
difficulties 

Compatibility 

The degree to which an innovation is 
perceived as being consistent with 
existing values, needs, and experiences 
of potential adopters 

1. Using the system is compatible with all 
aspects of my work 

2. 1 think that using the system fits well 
with the way 1 like to work 

3. Using the system fits into my work style 


Table 5. Facilitating Conditions: Root Constructs, Definitions and Scales 

From (Venkatesh, V. et al. 2003) 


Perceived behavioral control is significant in both voluntary and 
mandatory settings especially immediately after training is conducted on a new 
system but tends to become non-significant by at least 1 month after 
implementation. Facilitating conditions have been found not to have a significant 
influence on behavioral intention but do seem to have a direct influence on usage 
beyond factors explained by behavioral intentions alone. Facilitating conditions 
are also modeled as a direct antecedent of usage (i.e. not fully mediated by 
intention). In fact, the effect is generally expected to increase with experience as 
users of the new technology find different avenues for help and support 
throughout the organization. Studies in organizational psychology have found 
that older workers attach more importance to receiving help and assistance on 
the job (Hall and Mansfield 1995). Thus, Venkatesh et al. concludes, when 
moderated by experience and age, facilitating conditions have a significant 
influence on usage behavior. This effect becomes stronger for older workers, 
particularly with increasing experience. 

From a theoretical perspective, UTAUT provides a refined view of 
how the determinants and usage behavior evolve over time. It is important to 
note that most of the key relationships of the model are moderated. Age has 
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received very little attention in the study of technology acceptance research 
literature, yet numerous recent studies like UTAUT show that age moderates all 
of the key relationships. Gender, which has received more recent attention, is 
also a key moderating influence, however, it appears to work in concert with age. 
As more studies in sociology and psychology appear in an IT context, it is 
apparent that as the younger population of our workforce matures, gender 
differences, in how each perceives information technology may disappear. This 
is a hopeful sign and suggests that gender differences in the use of information 
technology may be transitory, especially concerning the younger generation of 
workers raised and educated in today’s digital age. 

2. Exploring a Revised UTAUT Model 

As discussed earlier in this section, we intend to use a second case study 
wherein UTAUT is used to explain users’ acceptance of new technology. In End- 
Users’ Acceptance of Enterprise Resource Planning Systems: An Investigation of 
Antecedents by Symour, L., Makanya, W., and Berrange, S., this phenomenon is 
further studied based on user acceptance of an ERP implementation at the 
University of Cape Town, South Africa. Symour et al., propose a research model 
that is an adjustment to the UTAUT and contains the dependant variable 
Symbolic Adoption that has been shown to better indicate end-user acceptance 
of mandatory technologies by Nah, Tan and Teh (2004). The research model 
was validated using a 2006 survey of users of the PeopleSoft Student 
Administration System at the University of Cape Town. The PeopleSoft system 
is mainly used for the maintenance of access to student related data and for 
student processes such as registration and graduation. 

Before we discuss the research methodology, data analysis and results of 
the study, it is important to briefly introduce the concept of implementing an ERP. 
Enterprise Resource Planning systems are made up of a suite of integrated 
software applications designed to support a business’ core functions. ERP 
systems help organizations reduce operating expenses and are intended to 
improve business process management through the integration of business 
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functions and information. Despite the advantages an ERP solution may provide, 
research finds that their adoption is often problematic. Approximately 50% of all 
ERP implementations fail to meet the adopting organizations’ expectations 
(Jasperson, Carter and Zmud 2005). End user resistance is one of the main 
contributing factors that lead to the failure of an ERP adoption and it has been 
found that user acceptance of a system is highly dependant on attitude towards 
the information system, their overall acceptance of the system, and the level of 
intended usage of the system. Examining these factors is therefore important for 
organizations that intend to or are installing ERP systems. 

Like the study conducted by Venkatesh et al., the Seymour et al. study 
used the UTAUT model with a few adjustments. The behavioral intention factor 
and the use behavior factor used in UTAUT were replaced with the symbolic 
adoption factor since it was viewed to provide a more suitable measure of end- 
users’ acceptance from an ERP perspective. To date the UTAUT model, in a 
strict sense, has not been used in validating an ERP implementation. Symbolic 
adoption, first hypothesized by Rawstorne et al. (1998), is used as an improved 
dependant variable and correlation between symbolic adoption and perceived 
ease of use. Symbolic adoption can be described as an end-user’s “mental 
acceptance of a new system (Nah et al. 2004). It is further suggested that end- 
users in a mandatory setting undergo symbolic adoption before actual system 
acceptance takes place. In a mandatory setting, end-users will demonstrate 
differences in symbolic adoption, which can be further investigated to evaluate 
and explain their acceptance levels of ERP systems. Figure 4 below represents 
the research model used by Symour et al. and can be compared to the 
Venkatesh et al. UTAUT model. Note that training, project communication and 
shared belief are used as facilitating conditions effecting symbolic adoption, 
where in the UTAUT model, facilitating conditions effect use behavior. 
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Figure 4. Seymour et al. Adjusted UTAUT Research Model 
From (Seymour, L. et al. 2007) 

Training, project communication and shared belief are now briefly described 
below to shed further light on the Symour et al. facilitating conditions 
methodology. 


a. Training 

Training has been identified as an important factor for implementing 
ERP systems and focuses generally on training length, timing and thoroughness. 
It is important to train users on a new ERP system because of the proven 
positive influence on end-user acceptance of the system. Training gives end- 
users time to adjust to the change that will occur and allows them to gain first 
hand experience and explore the usefulness of the system. Brown et al. (2002) 
noted how training increases the self-efficacy of end-users of ERP systems 
because they understand better how the system may improve their job functions. 
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b. Shared Belief 

Shared belief is defined as the end-users’ belief that the ERP 
system will have an overall positive effect on the organization. End users 
belonging to different functional areas of an organization make use of ERP 
systems when they believe those systems are going to help them integrate the 
organizations different business functions. The caveat is that all end-users of the 
ERP system must therefore believe that the ERP system will benefit the 
organization before it is accepted. Prior research in end-user acceptance of an 
ERP system indicates that if all end-users have a shared belief and an 
understanding of why the system is being implemented, including how it would 
benefit the organization and improve their work environment, the system will be 
more readily accepted. 

c. Communication 

An important factor in increasing user acceptance of an ERP 
implementation is early and effective communication with end-users. It is 
important for organizations to clearly justify the system’s benefits to establish a 
shared belief among the end-users that the system will provide better 
functionality within the organization. Doing this has been shown to curb end-user 
resistance and facilitate acceptance of an ERP (Oliver, D., Whymark, G., and 
Rohm, C. 2005). End-users who feel they are included in the decision to adopt 
an ERP system from the beginning, are more likely to accept it because 
communication provides information about the system and allows users to 
provide feedback on issues they may have. Thus, resistance to the new system 
is detected early and measures can be taken to counteract and correct aspects, 
which may negatively impact the implementation effort. 

Results from the Seymour et al. study correlate with the Venkatesh 
et al. study in that the UTAUT model could validate relationships among end user 
acceptance of a new system. In the Seymour et al. study, the independent 
variables accounted for 79% of the total variation in the dependant variable, 
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symbolic adoption, for older respondents. This percentage went down to 56% for 
the total group and further down to 39% for the younger respondents (where age 
>35 years old). In support of the literature, positive linear correlation was found 
between performance expectancy; effort expectancy; project communication; 
training and shared belief, and the dependant variable symbolic adoption. 
Together, as stated above, the models relationships accounted for 56% of the 
variation in symbolic adoption. While this is a good result, it also indicates that 
there are other variables not tested within this study which impact symbolic 
adoption. This study shows that similar supporting relationships exist between 
slightly different UTAUT models. Below is a list of the correlating relationships 
found in the Seymour et al. study. Notice the similarities of the relationships 
described in the Venkatesh et al. study. 

1. The relationship between effort expectancy and symbolic 
adoption is influenced by age, such that the effect will be 
stronger for younger respondents. 

2. The relationship between performance expectancy and 
symbolic adoption is influenced by age, such that the effect 
will be stronger for younger respondents. 

It was determined that age is a significant moderating factor 
between effort expectancy and usage of the system but that age was not a 
significant moderating factor between performance expectancy and system use. 
Support was also found for the following three moderating relationships: 

1. The relationship between shared belief and symbolic 
adoption is influenced by age, such that the effect will be 
greater for older workers. 

2. The relationship between project communication and 
symbolic adoption is influenced by age, such that the effect 
will be greater for older workers 

3. The relationship between training and symbolic adoption is 
influenced by age, such that the effect will be greater for older 
workers. 
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The findings of both the Venkatesh et al. study and the Seymour et 
al. study have high correlating relationships with respect to age. Gender was 
unable to be used as a moderating variable in the Seymour et al. study because 
there were only 3 male respondents in the data sample. Additionally the 
Seymour et al. study was not conducted as a longitudinal study and therefore 
levels of acceptance could not be validated at different points in the 
implementation. These two points limited the scope of the study, however, it is 
abundantly clear that the UTAUT model does validate the use of the four key 
constructs (Performance Expectancy, Effort Expectancy, Social Influence and 
Facilitating Conditions) and their moderators (Gender, Age, Experience and 
Voluntariness of Use) despite slight variance in use of the model in the case of 
Semour et al. 

Both studies point to the fact that further research in this area is 
critical in developing a better understanding on user acceptance of new 
technology. The findings in both studies indicate the relevance to future 
researchers and leaders within organizations intending to implement new 
systems. It is arguable among practitioners today, that getting end-users to use 
a new system correctly may be much harder and more important than actually 
implementing the system itself because the success of a system is generally 
measured on how well the system is used by end-users. 

B. ORGANIZATION ADOPTION CYCLES 

According to Moore’s Law, the number of transistors on a chip will double 
every two years (Moore 1965). Moore’s law can really be thought of as a 
forecast, revealing the continuous evolution, change and improvements in 
information systems technology. Constant changes can be overwhelming within 
a business organization attempting to maintain a competitive edge in an ever- 
expanding marketplace. An organization’s motives for adopting or not adopting 
new technologies vary from such things as necessity, opportunity and 
affordability. Worth mentioning is the fact that there are great many other 
motivating factors which moderate an organizations motives to adopt new 
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technology. For instance, an organization may upgrade to new software 
because not doing so would interfere with its user’s ability to accomplish key 
business processes. Additionally, an organization might adopt new software to 
capitalize on an opportunity that may lead to an advantage over its competitors. 
Sometimes organizations simply change to new software because of growing IT 
budgets coupled with perceived benefits in new and improved product versions. 
Another significant factor that entices organizations to upgrade old software is 
software manufacturer support and the licensing of their software products. 
Regardless of the reasons for change, upgrades in technology and in particular, 
software, are to be expected. 

Furthermore, in order for a business to survive in today’s fast paced 
corporate environment, their value chain will inevitably incorporate some sort of 
computing technology in daily operations. In fact, technology is embedded in 
every value activity in a firm, and technological change can affect competition 
through its impact on virtually any activity (Porter, M. 1985). These aspects have 
been thoroughly studied and documented and are in part, a motivating factor 
behind new software adoption practices essential in every organization. 

With the understanding that software will continue to change and improve, 
business managers struggle with the question of whether the current version of 
software is obsolete or outdated, and warrants an upgrade. The rest of this 
section will outline some of the critical questions that a manager must ask to 
determine if an organization needs to adopt new software, followed by some 
possible coping strategies when the choice has been made to do so. 

1. Critical Software Upgrade Questions 

How do managers within organizations determine if it’s time to upgrade? 

If managers felt that Windows XP for example, was still sufficient to satisfy their 
current business needs, should the organization still consider changing to the 
latest version of Windows Vista anyway? What are the factors, which might 
influence their decision? What implications does it have for their organization in 
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terms of the realignment of business operating procedures, processes, policies 
and doctrine? How much longer will the manufacturer continue to support the 
older version of software that the business is currently running and how does this 
timeframe fit within the organizations schedule and operations? These are some 
of the questions that organizations ask every time a new version of software 
package emerges from the market. But, deciding if and when to upgrade are not 
the only problems facing Information Systems (IS) management. They also have 
to be concerned with unexpected consequences that may occur due to the 
upgrade. Figure 5 below helps to identify key factors that can influence a 
software upgrade. 



Figure 5. Induced Model 
From (Khoo 2005) 
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According to Khoo, M., Huoi the six components in this model are; 
Motivating Forces, Decisions, Contingency Forces, Planned Strategies, Impacts 
and Corrective Actions. These components help to identify some of the key 
factors that drive software upgrades within an organization. 

a. Motivating Forces 

Motivating Forces can be broken down into two main categories: 
Internal Requirements, and External Dependency on Software Vendors. The 
Internal Requirements consist of: 

• Company Policy 

Organizations should develop a policy on software upgrades 
that helps to provide a step-by-step process to guide owners, 
managers, and stakeholders on what when and how to upgrade. 
It should govern what type of software should be adapted, when 
it is necessary, and guide the IT manager on choice of vendor 
and support required from the vendor. In addition it should 
provide some guidance on acceptable risks, investment price, 
and limitations for the total cost of ownership. 

• Manager’s Philosophy 

Every business has an internal structure designed to 
compliment the business process. In this model the manger is 
considered the decision maker. If he believes Information 
Technology is the key to success then he will push to upgrade 
the business software every time a new product is released to 
market. This may lead to a discontinuity between the user and 
organizational cycles. Referring to the user adaption cycle 
section; getting end-users to use a new system correctly may be 
much harder and more important than actually implementing the 
system itself because the success of a system is generally 
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measured on how well the system is used by end-users. There 
are many other factors that the manager must consider before 
making the decision to upgrade. 

• Business Needs. 

This is the most significant factor when considering internal 
requirements. This is where the balance between 
organizational functionality, business process and users’ ability 
to adapt to software upgrades can be analyzed and possibly 
synchronized. 

The External Dependencies consist of: 

• Software Functionality 

The possible benefit that the improved functionality of the new 
software offers plays a significant role in the decision process. 
However, when making this decision a manager must consider 
organizational resources, and the current organization’s 
process. This is where software vendors try to influence 
organizations by reducing the time it takes to release newer 
versions of software packages and marketing the upgrades that 
they have to offer. Organizations do not have the time to train, 
adapt and see return on investment before they are supposed to 
upgrade again. This can cause discontinuity between the 
Organization Cycle and the Software Development Cycle 
because software vendors continue to improve their ability to 
produce software at a faster rate, resulting in an organization’s 
inability to keep up. 

• Technical Support 

Vendors will continue to improve their software packages and 
release updated versions. This gives vendors a tremendous 
influence over the organizations upgrade decision cycle. 
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b. Contingency Forces 


Contingency forces are not as defined in this model, however, they 
play a key role in the decision process. Internal resources play a significant role 
in an organizations decision to upgrade. The availability of internal resources 
may not be the deciding factor on the decision to upgrade, however, the lack of 
internal resources can be the deciding factor in the upgrade decision (Khoo, 
2005). This implies that the motivating forces and internal resources act together 
to determine an organization’s decision to upgrade. 

c. Decision 

The two arrows drawn from the Motivating Forces and Contingency 
Forces to the decision component indicates that the decision to upgrade is the 
outcome of the interaction between contingency forces and motivating forces. 

The arrow pointing from the decision component to impacts, indicates that the 
decision to upgrade will have a positive or a negative effect on the stake holders 
(Khoo 2005). In addition, this will effect the users adaptation cycle, the business 
process, and ultimately the business capital. 

d. Impacts 

The impact component will cause a positive outcome, negative 
outcome or a combination of both. Every decision to upgrade will incur cost, 
however, the hope is that this cost will provide a return on investment and 
additional benefits. Impacts are difficult to assess, however, a software upgrade 
can be assessed through the implementation process, changes in packaged 
software, and other circumstantial impacts. (Khoo 2005). 

e. Corrective Actions 

Corrective actions can be thought of as a coping strategy. This 
type of action is a reactive method devised to cope with the negative impacts that 
a software upgrade has already caused. An arrow drawn from impacts to 
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corrective actions indicates the reactive nature of this component. Additionally, a 
negative sign indicates that the corrective action is the response to the negative 
impact that the software upgrade has caused. An additional arrow is drawn from 
corrective actions back to impacts to show the changes that have been made to 
counter the problem. One last arrow has been drawn using a dotted line to 
indicate some of the formalization of the corrective actions that should be used 
as part of the planned strategy for the next upgrade (Khoo 2005). 

f. Planned Strategies 

This strategy is for the sole purpose of reducing the negative 
impacts that a software upgrade may cause. It has several subcategories that 
play a role in mitigating negative software upgrade impacts. It has an arrow 
indicating a moderating relationship that is drawn from the planned strategy to 
the line connecting decisions and impacts (Khoo 2005). 

These business needs and requirements are part of what 
influences the decision to upgrade. “It is the fact of the organization’s 
dependence on the environment that makes the external constraint and control of 
organizational behavior both possible and almost inevitable” (Pfeffer and Salanik, 
1978). 


2. Software Implementation 

As vendors become more efficient at developing, marketing and 
distributing their product, organizations need to become more efficient at 
deciding why to upgrade, knowing how to upgrade and knowing when to 
upgrade. Whether it is packaged software, Enterprise Resource Planning (ERP) 
software, Service as a Systems (SaaS) software, or another type, these three 
questions are important for the successful integration of an organizational 
upgrade. Burton Swanson and Ping Wang from the UCLA Anderson School of 
Management, conducted an analysis of 118 firms and identified that a business’s 
coordination is closely identified as a know-why factor, and management 

understanding and vendor support as a know-how factor. These factors were 
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identified as vitally important to the success of organizational implementation of 
ERP software. The following are some further explanations and findings that 
relate to this paper. Figure 6 summarizes the success model according to 
Swanson and Pang. 


Context: Innovation Characteristics, Organization Characteristics 



Figure 6. Reasoned Innovation Model 
From (Swanson and Wang 2005) 

Specifications: (i) A firm’s innovation reasoning will be composed 
principally of know-why (for adoption) and know-how (for 
implementation). Its know-how reasoning will be informed by its 
know-why. (ii) A firm’s overall success with an innovation will 
depend substantially upon the know-why and know-how it brings to 
the undertaking. Assumptions: (i) Contextual variables will be 
reflected in a firm’s innovation reasoning (and actions), (ii) Afirm’s 
know-when (for its actions) will be implied by its know-why and 
know-how (Swanson and Wang 2005). 
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Swanson and Pang collected their data using a multi-year mail in survey. 
They found that the 118 companies were of different sizes with a median of 5000 
employees and quartile range of 1550-15000 employees. They also found that 
their Information Systems (IS) staff varied in a similar manner, with a median of 
140 information specialists and the quartile range of 32-400 specialists. After a 
complete analysis of the responses collected by the 118 companies they 
developed some key factors that are relevant to Know-why, Know-how, and 
success. Then they listed several indicators for each of the factors. The 
indicators are the answers to some of the questions in the questionnaire. The 
three factors related to Know-why are characteristics that show an adoption 
rational. The four factors related to Know-how are characteristics that show an 
organizational software adaption structure. A description of these factors and 
their indicators are listed inTable 6 below. 


Factor 

Item no. 

Judgmental statement in questionnaire 

Know-why 

Business coordination 

2 

This package provides features which enable us to work better 
with our suppliers and/or customers. 


46 

This package facilitates our user communications across departments. 

Application integration 

7 

This package enables us to bridge easily to other applications in our portfolio. 


23 

An advantage of this package is that it works with other 
packages from other vendors. 

External authority 

29 

This package was initially evaluated and recommended to us by a consultant. 


48 

Adoption of this package is a step toward outsourcing our IS department. 

Know-how 

Vendor support 

9 

This package is well maintained by the vendor. 


14 

This package is relatively free of bugs. 

Project planning 

6* 

We underestimated the amount of training needed to implement this package. 


13* 

We underestimated the amount of consulting we required to 
implement this package. 


25* 

We underestimated the time it would take us to implement this package. 

Management 

35 

Top management has provided us with the necessary resources to 

understanding 


successfully implement this package. 


39 

Our top management understands the costs to implement and 
maintain this package. 

Custom requirements 

4* 

We underestimated the amount of customization needed for this package. 


47* 

This package requires enhancements in order to better meet our needs. 

Success 

24 

Most of our users of this package are on the whole happy with it. 


33 

We are on track with our plans for the implementation and use of this package. 


55 

On the whole, our implementation of this package has been successful. 


Table 6. Key Factors 
From (Swanson and Wang 2005) 
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In order to explore the validity of their proposed mode,I they developed 
eight Structural Equation Models (SEM) using various combinations of the factors 
and their related indicators. The Models were labeled A-H. Swanson and Wang 
proposed that by comparing the relative fit for their multiple models they could 
show a logical progression using different factors on the same data. In addition, 
this would support specifications of theoretical models for future confirmatory 
studies. The models were constructed using a different combination of factors 
for the Know-why, Know-how, and success based on the limitations imposed by 
the questionnaire results and the 16 variable data shown in Table 6. “For 
instance, Model C consists of one Know-why factor (business coordination) and 
its indicators (Items 2 and 46), one Know-how factor (management 
understanding) and its indicators (Items 35 and 39), and the success factor and 
its indicators (Items 24, 33, and 55)” (Swanson and Wang 2005, p 24). After 
constructing the eight models they put each through a series of statistical tests. 
This mathematical analysis is outside the scope of this paper, however, the 
results are not. Table7 summarizes the standardized estimation results and 
goodness-of-fit for these models. Note: R 2 for success shows that Model C has 
the most variance (59%). R 2 is the root-mean-square error of approximation 
(RMSEA), for more information on RMSEA, see Hu, L.-t. and Bentler, P.M. 

(1999). Cutoff Criteria for Fit Indexes in Covariance Structure Analysis: 
Conventional criteria versus new alternatives, Structural Equation Modeling 6(1): 
1-55. 
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Model 



Item No. 

A 

B 

C 

D 

E 

F 

G 

H 

Know-how-* Success 










Vendor support 

9, 14 

0.47* 




0.55* 




Project planning 

6, 13, 25 


0.11 




0.34* 



Management understanding 

35,39 



0.37* 




0.50* 


Custom requirements 

4,47 




0.21 




0.38* 

Kno w-why —* Success 










Business coordination 

2,46 

0.51* 

0.63* 

0.59* 

0.61* 





Application integration 

7,23 





0.18 

0.24 

0.29* 

0.25* 

Know-why -» Know-how 


NA 

0.42* 

0.24 

0.32* 

0.24* 

0.22 

0.05 

0.15 

R 2 for success 


0.48 

0.46 

0.59 

0.51 

0.38 

0.21 

0.35 

0.24 

Model parameters 










Independence y 2 


231.81 

288.02 

183.53 

218.58 

228.70 

272.39 

184.29 

213.49 

Degrees of freedom 


21 

28 

21 

21 

21 

28 

21 

21 

Model x 2 


28.18 

41.45 

14.65 

15.16 

10.84 

34.76 

19.97 

15.41 

Degrees of freedom 


12 

17 

11 

11 

11 

17 

11 

11 

P-value 


0.01 

000 

0.20 

0.18 

0.46 

0.01 

0.05 

0.16 

Bentler-Bonett non-normed fit index 


0.87 

0.85 

0.96 

0.96 

1.00 

0.87 

0.90 

0.96 

Comparative fit index (CFI) 


0.92 

0.91 

0.98 

0.98 

1.00 

0.93 

0.95 

0.98 

RMSEA 


0.11 

0.07 

0.05 

0.04 

0.00 

0.10 

0.09 

0.06 

LISREL GFI 


0.94 

0.93 

0.97 

0.97 

0.97 

0.93 

0.95 

0.96 

Number of iterations 


7 

7 

7 

7 

6 

7 

7 

7 


‘Significant at 0.05 level. 


Table 7. Models A-H 
From (Swanson and Wang 2005) 


Swanson and Pang found that while all models proved to be beneficial in 
understanding software implementation, it was Model C that was best suited for 
explaining what factors are most important to implementation success. See 
Figure 7 for results on Model C. “Model C is our best model by both model-fit 
and R2 criteria It is composed of the business coordination know-why factor and 
the management understanding know-how factor, both of which are significant in 
explaining implementation success” (Swanson and Pang 2005, p 27). In addition 
they found that the business coordination, vendor support, and management 
understanding factors play a significant role in the success of the software 
upgrade process. 

These findings provide insight on some of the key factors necessary for an 
organization to be successful at software implementation. 
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3. 


Case Study on Windows Vista Implementation 


Dean Williams, a consultant for Softchoice Corporation conducted a study 
designed to determine if organizations were prepared to implement the software 
upgrade to Windows Vista (WV). The data from this study is an inventory 
collected from 112,113 desktops in 472 North American organizations. The 
organizations include companies from industry sectors in finance, healthcare, 
technology, education and manufacturing. The data was collected between June 
1 st and October 1 st of 2006. Williams found that over half of todays organizations 
did not have the hardware needed to adopt the minimum requirements for WV, 
and over 94% of the organizations did not have the hardware needed to meet 
WV premium package. Within these groups, he found that the majority only 
required minor upgrades, such as upgrading storage space or RAM, however, 
the rest were in need of major upgrades, such as graphics cards, and new 
processors. The necessary upgrade results can be found in Figure 7 below. He 
attributed this to several factors: 

• WV required a substantial increase in hardware resources 

• Many organizations had a hardware lifecycle that was in excess of 
five years. 

• A lack of easy access to the PC inventory information needed to 
implement an effective life cycle management. 
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CPU Hard Drive (Total Size) 



•Based on Windows Vista System Requirements 


Figure 7. Components Requiring Upgrades within the 50% not meeting 

requirements. From (Williams 2006) 

This study also indicated that from the release of Windows XP to the time of the 
study the PCs CPU speed had increased approximately 215 percent in five 
years, but the requirements for WV needed an increase of approximately 243 
percent. Figure 8 shows a comparison in the system requirements needed for 
the last four Microsoft operating system releases. 
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Figure 8. Percentage increases in system requirements, 2000-2006 

From (Microsoft) 

a. Future Preparedness 

The Williams study found that 27 percent of the organizations 
planned to wait one to two years before upgrading to WV. Another 33 percent 
planned to wait six months to one year before upgrading. This indicates that 
organizations do consider the software lifecycle. As organizations plan to 
upgrade to WV their PC lifecycle and current state is key to a smooth transition to 
WV. Swanson developed some recommendations which might be beneficial in 
planning the upgrade to Windows Vista. These recommendations can be seen 
on Table 8. 
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Vista Deployment Plan 

Recommended Action 

Benefits 

Immediately 

• Assess the ability of the current environment 
to supportVista. 

• Determine which machines will require 
upgrading or replacing. 

• Forecast necessary purchases with chosen 
hardware vendor. 

• Eliminate unexpected hardware 

expenses. 

& months - 1 Year 

• Assess which machines will not supportVista . Maximize vendor discount potential 

at the time of rollout. from hardware forecasting. 

• Determine which machines will require . Recoup optimal value from PCs slated 

upgrading or replacing. f or retirement. 

• Forecast necessary future purchases with . Streamline upgrading and deployment 

chosen hardware vendor. process - Reduce unexpected IT 

• Adjust current hardware purchasing resource strain. 

standards to meet Vista requirements. . p ro j ect total cost 0 f Vista deployment. 

1 Year-2 Years 

• Assess which machines if any will not support 

Vista at time of rollout. 

• Adjust current hardware purchasing 
standards to meet Vista requirements. 


Table 8. Actions and Benefits for Windows Vista Deployment 

From (Williams 2006) 

While organizations tend to focus on upgrade implementation 
factors and lifecycle aspects of new software, the Williams case study shows that 
hardware lifecycle and purchasing decisions for that hardware are significantly 
related to a successful software upgrade. 

C. SOFTWARE INDUSTRY DEVELOPMENT CYCLES 

Software vendors, both large and small, often produce and market their 
products faster than organizations and users can adapt to them. This trend is 
evident to software industry observers and practitioners alike. Reducing the time 
to market is a top priority for most software vendors as they try to take advantage 
of benefits such as extended market life, increased market share and greater 
freedom in pricing. Many companies try to gain competitive advantage by 
exploiting these benefits in the marketplace by shortening their development 
cycles and rushing their products to market, however, studies have shown that 
this practice can lead to undesirable consequences. The trade offs for pushing 
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software to market and reducing production cycle times leads to buggy software 
products, aberrant development practices and increased strain on software 
engineers (Sims 1997). 

Table 8 below shows the evident shrinking cycles times according to a 
Product Development and Management Association (PDMA) survey of about 200 
U.S. companies in a variety of industries. 


Type of new product 

1990 average 
development time 

1995 average 
development time 

Breakthrough products 

49 months 

42 months 

New product lines 

35 months 

29 months 

Major product revisions 

22 months 

18 months 

Minor product revisions 

10 months 

8 months 


Table 9. PDMA survey on shrinking cycles in product development 

From (Sims, D. 1997) 


The shrinking cycle times displayed in Table 6 are from figures between 
1990 and 1995, and reflect that decreasing time to market trends are not a new 
occurrence. Today, some observers claim that the Internet has added to the 
reduction of time to market methods because it has made it easier for vendors to 
distribute beta versions of products for testing. Although this theory is plausible 
and no studies were found to refute this theory, some suggest that it’s not the 
proliferation in use of the Internet that has contributed to faster production 
development of software, but the market itself and today’s global economy is to 
blame. Organizations and businesses worldwide are in a constant search for a 
competitive advantage and more often, management personnel are focusing on 
software and new technologies to expand the gap between their companies and 
the competition. Thus, reducing the time to market is more than just a goal for 
most vendors in the computer software industry; it has become the focus for 
survival in a highly competitive market. 
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1 . 


Vendor Benefits from Improving Development Times 


There is no doubt that one of the most important considerations in 
commercial software development is that of meeting projected market release 
deadlines (Collier, K. and Collofello, J. 1995). The benefits reaped from 
improving software development times are many, but the most obvious benefit is 
the fact that the earlier the software is released the more time the product is 
given to generate sales and revenue. The introduction of software on the market 
sooner does not mean that it becomes obsolete any faster. Research in software 
cycle time development suggests that the time of obsolescence remains fixed 
regardless of the time of introduction. Additionally, studies indicate that switching 
software has a high cost because users of software tend to become loyal to their 
software products. This is mainly due to the high costs and learning times 
associated with switching to new applications. Another benefit lies in the fact that 
shorter development cycles can also increase market share. For example, the 
first product to market, which provides a new capability or new function, will 
initially hold 100% of the market share. This, together with the high switching 
costs, will increase a vendors ability to obtain and retain a large market share. 
Still, another benefit is the likelihood of higher profit margins. When a vendor 
speeds up development cycles, costs are likely to decrease. Additionally, 
shortening a products time to market allows for greater freedom in pricing. Earlier 
release of contract software usually means an increased chance in obtaining 
contracts earlier than their competitors and, together with lower development 
costs, may provide a greater profit margin. Last, shortening software cycle times 
allows engineers to start later in the development process, which allows them to 
take full advantage of any technological advances that constantly occur in 
today’s fast paced technical environment. 

2. Money, Time and Quality 

As eluded to in the paragraph above, software vendors have the 
opportunity to save money, increase profit margins and take advantage of ever 
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evolving technologies from increasing development cycle times, however, 
tradeoffs usually occur at the expense of quality and product performance. 
Software companies must make trade-offs to deliver products in a hurry. Money, 
time and quality are the main factors being juggled by vendors and eventually, 
one factor is relaxed at the expense of another. (Carmel 1995). In many cases 
today, developers may knowingly deliver buggy products in order to meet time to 
market and cost constraints. Recent studies suggest that time to market is the 
overriding concern for all managers and have shown that marketing managers 
are more concerned about features and platform diversity than about quality. For 
example, companies often inadequately document projects and inadequately 
staff quality assurance teams (Barr, A. and Tessler, S. 1996). Bar and Tessler 
also note that workers in quality assurance are often assigned a lower status 
than other members of project teams, giving them less influence over the 
development process and in some cases aren’t even given enough time to test 
products before they go to market. Bar and Tessler’s survey of eleven firms 
within the relational database management systems (RDBMS) and call center 
management segments of the software industry found that: 

1. In both segments, (RDBMS and call center software), features, 
quality and cost were consistently traded off to achieve time to 
market. 

2. No dominant software development methodology was identified. 
Only 50% of their respondents described any formal methodology. 
Most were developed in house. 

3. A majority of teams allowed features to be added or dropped very 
late in the development process, even after beta testing. 

4. Product decisions in more than half the firms were dominated by 
Engineering. Less then 20% of the respondents made decisions 
based on consensus between Engineering and Marketing. 

5. Code re-use, from prior versions (91 %), other company code 
(54%), and commercial products (27%) was very common. 
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6. Project level budgeting and cost tracking were low-priority activities. 
Head count was the only budget control mentioned. 

7. Major differences in perception exist between the Marketing 
Product Manager and his or her counterpart in Engineering about 
such issues as how the requirements for the release were 
formulated, tradeoffs, the nature and source of development 
problems, etc. 

8. Project teams were organized in a variety of ways. Functions like 
Quality Assurance and Release/Project Management could be 
located in several different departments and at different levels 
within the department, and even documentation and Tech Support 
held a variety of organization chart positions. 

The results of the survey indicate that time to market is the key driver for a 
variety of software vendors, even at the expense of quality, managerial practice 
and employee considerations. Software industry executives often claim that the 
extremely rapid rate of change in their technologies and markets force them to 
make conscious tradeoffs among cost, quality and features in the course of their 
software development. Marketing managers, for example, conclude features and 
platform diversity to be the essential drivers contributing to competitive 
advantage. Consequently, tradeoffs between money, time and quality are having 
significant impacts on organizations and users of new software. As mentioned in 
section 1, a 2002 study commissioned by the National Institute of Standards and 
Technology found software bugs cost the U.S. economy about $59.5 billion 
annually. The same study found that simply by improving testing through Quality 
Assurance could have mitigated more than a third of that cost -about $22.2 
billion. 

Not only is money being potentially wasted because of the tradeoff 
situation, as described earlier in this chapter, user acceptance and resistance to 
adoption present further problems for organizational software upgrades as well. 
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These factors all contribute to the notion that disjointed cycles among users, 
organizations and the software industry are ever present in today’s fast paced 
environment. 

3. Lessons for the Software Industry 

As stated earlier, time to market is a fundamental competitive strategy in 
the software industry. It’s safe to assume that today’s software vendors face 
increasingly intense competition due to the proliferation of personal computer 
technology. However, software product development managers appear to be less 
concerned with, or even aware of, cycle time than they are with other competitive 
variables (Carmel, E. 1995). In a study conducted by Erran Carmel, 15 small to 
medium sized software package developers were found to be generally unaware 
of cycle time reduction as a management concept. He concluded that software 
development companies tend to focus on rapid development and deadlines and 
found that during peak periods of activity, 87% of the developers in core teams 
worked more than 56 hours per week and 47% worked more than 71 hours per 
week. These findings add to the speculation that developers are susceptible to 
becoming stressed-out and unhappier with shrinking cycle development time, 
which may end up having adverse effects on their products, such as quality and 
buggy software. This problem suggests that in order to remain competitive, 
software developers need to determine how they can better integrate quality 
assurance activities into their development process while reducing cycle time. In 
the survey he conducted on 15 software development firms, Carmel found that 
only 2 out of the 15 companies used process models or risk analysis techniques 
and that most could not articulate even an end-of-cycle tradeoff scheme that 
would represent an elementary type of risk analysis. Similarly, he found that they 
devoted scant resources to automated tools and relied heavily on software reuse 
and incremental innovation. Figure 8 below represents how much money the 
firms spent on automated tools. More than half the companies, for which there 
was data, spent less than 1000 dollars per year per developer on outside 
software tools. 
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Dollars per davelopsr/ year 


Figure 9. Spending on Software Design, Development and Testing Tools 

From (Carmel, E. 1995) 

Although these companies reported that they made use of other sources 
to attain software tools, such as freeware, shareware, and trial versions of other 
vendors’ software, the use of automated tools still appears low (Carmel, E. 
1995). 

In light of Carmel’s findings on cycle time awareness, tradeoffs and cycle 
time reduction variables, he describes 5 lessons useful to software vendors in 
practice and theory. These 5 lessons are important to our study because they 
reveal vital steps software vendors can implement which can lead to reductions 
in cycle times and help users and organizations effectively and efficiently adopt 
new software. 


a. Lessons for Practice 

Lesson 1: The Core Team is a Key Success Factor. Carmel’s study 
indicated that in almost all companies, the respondents pointed to team related 
factors as a key to their success and a key to their ability to develop software 
rapidly. Apparent was the fact that software companies consider a highly 
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effective, organic, entrepreneurial, organizational structure to be a key success 
factor in reducing cycle times. For example, if a company’s cycle time was 
considered to be “good” (fast, approaching optimum), it was mostly contributable 
to the organizational variables listed above. If their cycle time was considered to 
be “inadequate”, the companies attributed it to the lack of organizational 
management variables. The sample firms surveyed in the Carmel study 
encompassed firms that were, by and large, young companies where their 
organizational team structures formed organically. A well functioning organic 
team is the strongest type of team (Hofstrand, D. 2007). It displays synergy - the 
results produced by the team are greater than the sum produced by each 
individual team member. Synergy occurs because the team uses the strengths of 
each member while minimizing the weaknesses of each. The organic team is 
often used in situations where all of the team members know how to carry out the 
responsibilities of each of the team members, but inherently important in this 
structure is the need to have an intimate knowledge of the other team members. 
Our findings suggest it is quite apparent that within larger software firms, organic 
team structures need to be fostered and nourished to replicate the desirable 
entrepreneurial spirit usually found in smaller software development teams. 

Lesson 2: Quality Issues Significantly Affect Cycle Time and Merit 
More Managerial Attention. Carmel notes that the software product category has 
inherent quality problems and he argues that there is no other product category 
in which products are routinely released with so many defects. Testing is 
identified as one of the largest components in quality assurance and is also one 
of the most difficult tasks in software development category. This is because any 
software program can have an infinite number of logic branches and testing 
every logic branch is too monumental of a task, taking up valuable time and 
resources. Although no evidence suggests that quality assurance activities 
shorten or lengthen cycle time, it is evident that a quality control regime involved 
in the process implies that if things are done right early, vendors can decrease 
expensive error correction late in the development cycle. Today, software 
packages are released with long lists of known defects and bugs, however, it is 
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still not clear in today’s market, whether the market would wait for near zero 
defect software products. Zero defect products may also be rejected by the 
market because of the high cost associated with high quality assurance 
standards. Thus, appropriate risk analysis techniques need to be developed and 
studied to manage these tradeoffs correctly. Carmel suggests that as the 
software industry matures and users become more demanding with regards to 
quality, more attention needs to be given to quality assurance and near defect- 
free software. Further studies in this field are needed to identify the effects this 
will have on time to market, but as of now, observers in this field agree that 
unless active steps are taken to integrate quality assurance into the development 
process, near zero-defect strategies will have an adverse impact on a product’s 
time to market. 

b. Lessons for Cycle Time Theory 

Lesson 3: Trade-off Research Needs to Include Quality. Carmel 
describes the tradeoff concept as one in which “units” of quality are decreased to 
allow additional “units” of features within a given time period. Table 9 shows 5 of 
the 15 firms’ responses to the statement: Given 100 possible total points, allocate 
the points to the 5 items, weighted by importance to success. The 5 items being 
Cycle Time, Features, Quality/Defects, Cost of Development, and Product 
Pricing. 


.Points Allocated to ... 

Cycle Quality/ Cost of Product 


Firm 

Time 

Features 

Defects 

Development 

Pricing 

Total 

3 

JO 

30 

10 

10 

N/A 

100 

4 

JO 

10 

20 

20 

N/A 

100 

5 

40 

40 

20 

0 

N/A 

100 

11 

0 

40 

23 

3J 

0 

100 

14 

IJ 

80 

3 

1 

1 

100 

Average 

31 

40 

16 

13 

N/S 

100 


Figure 10. Self-Reported Trade Offs for Successful Product Development 

From (Carmel, E. 1995) 
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The figure shows how software development companies view the items cycle 
time and features as much more important to overall product success than 
quality and defects. Tradeoff results depicted in Figure 6 and earlier discussions 
on software defects show that software managers trade units of quality for other 
product goals whether explicitly or implicitly. Further research in this field needs 
to be conducted but it is important to note that tradeoffs in product innovation can 
be understood within the framework of risk analysis techniques. Understanding 
the principals and practices of risk analysis in software development can help 
developers understand the consequences of tradeoffs more thoroughly. 

Additional research on cycle times should focus on the examination of the 
relationships between managers’ tradeoff preferences, the deliberate actions 
they take and cycle time outcomes. 

Lesson 4: Distinctions Between Cycle Time Awareness Levels 
Affect Cycle Time Reduction Behavior. Carmel found that software development 
firms’ actions and processes are driven by what is termed as a desire for rapid 
development, rather than deliberate action driven by overall cycle time 
considerations. This distinction was made to differentiate pre-cycle and early- 
cycle developmental approaches from reactive, late-cycle approaches. Because 
cycle time research is concerned with strategies for cycle time reduction rather 
than other coincidental factors, it must examine the awareness of cycle time 
reduction as various strategies and actions are applied. This methodology is 
necessary to help facilitate understanding which strategies work and which ones 
just happen to be present. That is to say, we need to understand which specific 
actions managers take to reduce cycle time, rather than to achieve other goals 
such as better design, lower cost, etc. This in-depth kind of research will allow for 
greater understanding of the variables that have a true impact on cycle time 
reduction. 

Lesson 5: Software Versions Are Tied to Market Rhythms that May 

Lessen Pressures for Cycle Time Reduction. Software package versions create 

both positive and negative effects on cycle time reduction. The positive effect is 

that software versions are typically advanced in incremental innovation. New 
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versions encompass incremental changes thus contributing more easily to 
quicker cycle times. The negative effect in the version concept is manifested 
through an entrapment into the software market rhythm. Most of the software 
industry releases new version every 12 to 24 months. This is viewed by the bulk 
of personal computer software users to be common managerial strategy in this 
industry. Carmel notes that the structural dynamics of the market rhythm are 
such that customers have an ambivalent approach to adopting new versions. On 
one hand, they desire the latest features offered by the new version, but on the 
other hand, they realize that the upgrade involves at least some investment of 
time or other resources like training budgets. For this reason, few customers 
choose to upgrade to new versions too frequently. Consequently, both customers 
and vendors tend to slip into the market rhythm, which cycles at 12 to 24 months. 
This phenomenon requires future studies relating industry specific market 
rhythms when examining and comparing cycle times. Establishing bench mark 
cycle times within various software companies and organizations will shed further 
light on which improvements can be compared. 
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IV. CONCLUSIONS AND RECOMMENDATIONS 


A. ANALYSIS AND RECOMMENDATIONS 

The software industry is in the midst of a dramatic revolution according to 
2006 software industry report conducted by McKinsey & Co. and the Sand Hill 
Group. The implications of this revolution are increased innovation, new business 
models, technology discontinuities, and global capability shifts. The report 
indicates that the software industry is experiencing an increased flow of internal 
and external capital and substantial innovation as well as increased private 
equity investments and expected increases towards IT budgets in the coming 
years. In fact, software budget growth is expected to gain 5% between 2006 and 
2008, from 30% to 35% (Berryman et al. 2006). Taken together, these factors 
and changes will have profound implications for software providers, organizations 
and users. 

This chapter will focus on identifying possible recommendations for 
software executives, managers and leaders where inevitable cyclic 
discontinuities exist between their organizations, users and the software industry. 
In taking into consideration the various advantages and disadvantages within 
user cycles, organization cycles, and the software industry’s cycles, we intend to 
shed further light on what IT managers can learn, expect and take action on. 

First, it is important to list and describe those attributes, which are 
considered to be advantages and disadvantages with respect to software cycles. 
In Figure 2 of Chapter II, we introduce the conceptual framework of the Software 
Upgrade Cycle. Below is an extension of the same figure with corresponding 
driving forces associated with the cycles of users, organizations and the software 
industry. 
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Life Cycle Management 

Upgrade/Implementation 

Predictability 

Business Process 

Social/Internal/External 

Influences 

Planning/Implementation 

Strategies 



Users 


Organization 


Software Upgrade Cycle 


Software 

Industry 


Performance Expectancy 
Effort Expectancy 
Social Influence 
Facilitating Conditions 


Adoption Cycle 


Adaptation Cycle 


Time to Market Practices 
Trade Offs 

Sales, Revenue, Market Share 
Software Development Teams 


Introduction Cycle 


Figure 11. Software Upgrade Cycle with Corresponding Driving Forces 


As described in the preceding chapters, driving forces within 
organizational adoption cycles, user adaptation cycles and introduction cycles 
within the software industry influence the software upgrade cycle phenomenon. 
To better delineate these moderators, which effect each cycle, we introduce the 
advantages and disadvantages inherent among the driving forces. The tables 
presented on the following pages describe attributes which positively and 
negatively effect the software adoption cycle as a whole and therefore should be 
of vital importance from the perspective of executives, managers and leaders 
within the IT industry. The first table delineates advantages and disadvantages of 
the user adaptation cycle. 
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Advantages and Disadvantages of the User Adaptation Cycle 


Advantage 

Disadvantage 

Performance 

Expectancy 

Men and younger women believe 
use of the system may allow 
increased productivity, 
effectiveness, ease of use and 
faster accomplishment rates. 
Rewards and benefits from using 
the system may be perceived to 
be higher among this group. 

Job related factors become less 
significant for working women 
between the time they enter the 
labor force and the time they 
reach child-rearing years. This 
group may be less inclined to 
initially perceive the rewards and 
benefits of a new system as 
advantageous. 

Effort 

Expectancy 

Women, particularly younger 
women in the early stages of 
experience may perceive use of 
the system to be free of effort, 
easy to understand and easy to 
use or interact with. Women may 
initially be more accepting of the 
new system as a result. 

Men and older women may be 
less inclined to initially accept the 
change to a new system. 
Perceptions may lead them to 
believe the degree of ease and 
flexibility associated with learning 
the system may be difficult. 

Social 

Influences 

Women, especially older women 
and older workers in general are 
more sensitive to others’ opinions 
and place increased salience on 
social influence. This group may 
be more voluntary in acceptance 
and initial use of a new system. 

Younger workers and workers in 
later stages of experience may 
place less salience on social 
pressures and influences. This 
group may be less inclined to 
accept use of a system based on 
others’ expectations even when 
those referent others have the 
ability to reward the desired 
behavior or punish non-behavior 

Facilitating 

Conditions 

Older workers, particularly those 
with more experience attach more 
importance to receiving help and 
assistance. This group perceives 
given the resources, guidance, 
opportunities and knowledge it 
takes to use the system, the 
system would be easy to use and 
compatible with aspects of their 
work. 

Younger workers with less 
experience may place less 
importance on receiving help and 
assistance with a new system 
within their organization. 


Table 10. Advantages and Disadvantages of the User Adaptation Cycle 

The second table delineates advantages and disadvantages within the 
software industry’s introduction cycle. 
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Advantages and Disadvantages within the Organization Adoption Cycle 



Advantages 

Disadvantages 

Life Cycle Management 

- Replaces old outdated 
legacy systems 

- Improves user interface and 
increase user satisfaction 

May increase productivity 

- Compatibility complications 
with legacy software or 
systems often cause projects 
to go over budget and exceed 
expected project completion 
dates. 

- May decrease productivity in 
initial stages of implementation 

Upgrade/Implementation 

Predictability 

- Improved cost analysis 

- Improved functionality 

- Improved perception of 
reliability 

- Adoption of poorly tested 
software or poorly QA tested 
software requires rework, bug 
fixes and patches or further 
upgrades 

- Unpredictable software often 
leads to dissatisfied user 
experiences 

Business Process 

- Standardization of business 
process 

- May help to implement 
change and enhance 
competitive edge 

- Become incompatible with 
some customers who still have 
legacy systems. 

Social, Internal and 
External Influences 

- Improve customer relations 
and customer service 

- Improve employee job 
satisfaction 

- Portray a successful 
business image with the most 
up to date software. 

- Bad press or negative public 
perceptions about an 
organization’s IT systems may 
effect stocks, sales 

- Pressures to contribute more 
assets to IT may take away 
assets from other aspects of 
an organization 

Planning/Implementation 

Strategies 

- Facilitates improved testing 

- Establishes good foundations 
in IT policy 

- Provided experience in 
implementation approaches 

- Enhances learning 

- Helps to mitigate negative 
impacts caused by software 
upgrades 

- Takes time 

- Untested strategies may 
require rework in production 
phases 

- Lends to tradeoffs if project 
deadlines can’t be achieved. 


Table 11. Advantages and Disadvantages within the Organization Adoption 

Cycle 


The third table delineates advantages and disadvantages within the 
software industry’s introduction cycle. 
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Advantages and Disadvantages within the Software Industry’s Introduction 

Cycle 


Advantages 

Disadvantages 

Time to Market Practices 

- Get products to market 
before competitors 

- Release a greater amount 
of products in the same 
amount of time 

- Avoid criticism in the 
media about not having up- 
to-date products 

- Deliver products before 
customers can change their 
requirements 

- Buggy products 

- Inadequate product 
documentation 

- Reliance on aberrant 
development practices 

- Increased strain on 
engineers 

- Customer aggravation 
about systems changing 
before they can be fully 
deployed 

Trade Offs 

- Cycle time reduction 

- Cost of development may 
decrease 

- Dropped features 

- Quality decreases and 
defects increase 

- Product support may 
decrease 

- Lends to increased 
patches and upgrades later 
in cycle 

Sales, Revenue, Market 
Share Strategies 

- Allow product pricing to be 
flexible 

- Tested strategies may 
support competitive 
advantage 

- Saving money on 
development allows for 
larger budgets in other 
business areas such as 
marketing 

Decreased budgets, time 
constraints adds pressure 
to development teams and 
lends to tradeoffs 

Lends to increased product 
revision cycles 

Untested strategies may 
decrease competitive 
advantage 

Development Teams 

- Cross functional team 
structure leads to better 
cooperation, faster 
decisions, shared 
responsibilities 

- Small teams have positive 
effect on intra-team 
communication 

- Success is determined by 
application specific 
experience of team 
members 

- Dispersed or non co¬ 
located teams have 
difficulties communicating 

- Inexperienced team 
members may cost in time, 
money and rework required 


Table 12. Advantages and Disadvantages within the Software Industry’s 

Introduction Cycle 
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B. TIMING AND FLEXIBILITY 


As this study suggests, many factors effect the timing associated with 

users, organizations and the software industry such as software life-cycle trends, 

environmental factors, market rhythm, budgets, management practices, policies 

and models, just to name a few. Most software companies release new major 

versions of their products every 12 to 24 months and minor revisions every 6 to 

12 months, while upgrades and service patches can be introduced in a matter of 

days (Carmel, E. 1995 and Sims, D. 1997). Although more research needs to be 

completed in user acceptance timing, the Venkatesh et al. and Seymour et al. 

studies indicate that the majority of users, despite usage intent fluctuations, can 

adapt to major revisions or completely new versions of a single software 

application within 12 months. More complex software packages including 

Software as a Service (SaaS) packages and business solutions software 

packages, such as those products produced by SAP, PeopleSoft, IBM and 

Oracle, may take longer than 12 months for an organization’s users to adapt to 

successfully. Integrating these more complex solutions or multiple software 

packages simultaneously can present organizations with myriad obstacles in the 

areas of user adaptation and organizational implementation. From an executive 

or managerial perspective, these obstacles need to be understood, anticipated 

and managed appropriately. The three tables we have presented in this section 

are relevant in that they identify both moderators and advantages and 

disadvantages managers can use towards a software integration plan. Both large 

and small organizations alike should be able to correlate and use at least some, 

if not all, of the aspects outlined in this section’s tables in IT implementation 

processes. Admittedly, every organization will be different in size, managerial 

dynamics, policy processes, employee composition and other factors. But in 

some way, every organization will use some type of technology infrastructure and 

it is for this reason, the following tables will prove beneficial. As organizations 

decide to upgrade and integrate technological aspects within their various 

processes, our suggestions represented in the tables will allow management to 

focus on how their users will adjust to the adaptation and implementation 
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strategies employed. Our suggestions and recommendations concerning the 
various software vendors they rely on will give managers a better idea about 
when implementing new software might be appropriate and advantageous in 
terms of competitive advantage perspectives. Finally, our suggestions and 
recommendations presented in the organization table will provide managers with 
reasonable explanations as to why their organization should consider new 
software implementations and integrations. 

C. STARTING POINT IN USING THIS RESEARCH METHOD 

Inevitably, executives and managers will ask these few and seemingly 
simple questions, which permeate not only the IS field but the manufacturing, 
marketing, sales, supply and human resource fields as well: What do I 
want/need, what can I afford and what or how can I integrate quickly. This 
section will focus on these questions as a starting basis while applying the 
software upgrade cycle and corresponding driving forces presented in this paper, 
as a tool to prepare practitioners and managers for a software upgrade. The 
following tables will outline the moderators and driving forces of each cycle 
(software industry, user, organization) and then present proposed considerations 
and actions to be explored. The proposed solutions are not all encompassing as 
there are too many influencing factors which may affect each particular upgrade; 
however, these are common considerations and actions that should be 
thoroughly explored when deciding to implement major and minor software 
upgrades. First, we introduce those considerations and actions to be explored 
from the software industry perspective. 
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Software Industry Proposed Considerations and Actions 

Time to Market Practices 

T rade-offs 

Sales, Revenue, Market Share 
Strategies 

Development Teams 

- Explore the reasons why a software 
manufacturer or vendor has released their 
product and under what circumstances. When 
was their last major revision or upgrade and 
how often do they introduce patches or 
revisions? These questions relate to the 
software company’s business practices and 
strategies. 

- Explore, if feasible, what trade-offs were 
made prior to release. Explore the company’s 
development process and team dynamics 
(size, pressures, incentives, experience). 

- Try to ascertain the company’s incentives in 
product release timing and make any 
correlation to sales and market share 
strategies. Are these correlations consistent 
with their prior major/minor releases? 

- Assess the company’s reliability as it pertains 
to Quality Assurance and product support. 

- Explore any other organization’s prior 
implementation of the software and make note 
of important lessons learned or compatibility 
issues. 


Table 13. Software Industry’s Cycle and Proposed Considerations and 

Actions 


The next table presents those considerations and actions, which should 
be explored from the organization perspective. Again, these considerations do 
not encompass all aspects that should be studied, but merely represent a subset 
of common hurdles and influencing factors of which executives and managers 
should be fully aware of. 
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Organization Proposed Considerations and Actions 

Life Cycle Management 

Upgrade/Implementation 

Predictability 

Business Process 

Social/Internal/External 

Influences 

Planning/Implementation 

Strategies 

- Assess where your organization is with 
respect to the life cycle of your present 
software systems and determine if and what 
kind of upgrades are feasible (major revision, 
minor revisions, patches) Are those revisions 
compatible with the current architecture? 

- Assess how predictable the proposed 
upgrade is with respect to Ouality Assurance 
and testing initiatives conducted by the 
vendor/manufacturer? 

- Explore your organization’s business and 
implementation processes and policies. Does 
your organization have a codified process and 
how effective was it in previous 
implementations? 

- Become familiar with the reasons why your 
organization is considering upgrading and 
determine if influencing factors align with 
current business goals. Is it feasible according 
to cost, time and benefits gained? 

- Assess your organizations capacity to 
effectively plan and implement new software. 

Is there a current strategy your organization 
uses or can adopt from elsewhere? 


Table 14. Organization Cycle and Proposed Considerations and Actions 


The last table presents those considerations and actions, which should be 
explored from the user perspective. Each organization’s users can represent a 
unique mixture of experience, gender and age and also may comprise as many 
as a hundred thousand to as little as a dozen users. This diversity can lead to 
conflicting adaptation consequences, nevertheless, each executive or manager 
must decide on appropriate implementation strategies, adapt to changes and 
mitigate problems as best they can. The below recommendation should prove 
valuable to a great many managers as they consider the composition of users 
within their organization. 
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User Proposed 

Considerations and Actions 

Performance Expectancy 

Effort Expectancy 

Social Influence 

Facilitating Conditions 

- Determine the experience, age and gender 
composition of your organization. Explore the 
factors of performance expectancy and effort 
expectancy as they relate to specific gender 
and age attributes. Does your organization 
comprise a majority of men or women and how 
does this effect how they interpret ease of use 
and effort required? 

- Determine the amount of users who may be 
more susceptible to social influence and 
develop training and implementation strategies 
that work in unison with this factor (i.e. Mentor 
programs) 

- Assess the conditions that may improve or 
place more importance on receiving help and 
assistance from others in the organization. 

Take steps towards improving the facilitating 
conditions that may be weak in areas (i.e. 
encourage younger workers to ask questions 
and seek help from more experienced workers. 


Table 15. User Cycle and Proposed Considerations and Actions 


D. FUTURE DIRECTIONS CONCERNING THE USER CYCLE 

Venkatesh et al. concluded that the Unified Theory of Acceptance and 
Use of Technology (UTAUT) theory explains as much as 70 percent of the 
variance in intention to use new software. It is possible, however, that we could 
very well be approaching the practical limits of our ability to explain individual 
acceptance and usage decisions in organizations. Future research therefore 
should focus on identifying additional constructs and moderators that can add to 
the prediction of intention and use behavior over and above what is already 
understood. The theories used in this paper facilitate the advancement of 
individual acceptance research by unifying several theoretical perspectives 
presented by Venkatesh et al. and Seymour et al. Common in this literature is the 
incorporation of four moderators to account for the dynamic influences including 
organizational contexts, user experience and demographic characteristics. 

Further research focusing on these and other factors can shed further light on 
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this phenomenon and add to the proliferation of competing explanatory models, 
which intend to explain individual acceptance of information technology. 

E. FUTURE DIRECTIONS CONCERNING THE SOFTWARE INDUSTRY 

CYCLE 

It is apparent that cycle time reduction will continue to be a primary goal of 
competitive software development organizations for the foreseeable future, yet it 
is questionable whether or not a significant reduction in cycle time can be 
achieved at a low cost, with minimal impact on software quality and performance 
(Collier and Collofello 1995). It is therefore imperative for practitioners to gain a 
better understanding of what leads the software industry to the reduction of cycle 
time. A number of future research directions should be focused in the direction of 
trade off factors. This important aspect should be further explored, especially with 
respect to the role of quality assurance as well as the covariance of cycle time 
awareness with cycle time outcomes. In general, the software industry needs to 
explore ways to increase quality assurance objectives while decreasing cycle 
time. Other industry efforts need focus in establishing cycle time benchmarks, 
software reuse strategies and other organizational and use of experience 
techniques. 

F. FUTURE DIRECTIONS CONCERNING THE ORGANIZATION CYCLE 

When innovating with IT, organizations have arguably given less attention 
to the lasting quality of their strategic know-why reasoning discussed in chapter 
3, than they have to the metrics of the investment moment (Swanson and Wang 
2005). Comparative organizational case studies and innovation case studies 
focused on how and why organizations adopt new technologies are required to 
further understand their strategic reasons. Our findings suggest that further 
studies should examine in depth how organizations go about comprehending, 
adopting, implementing and assimilating an IT innovation. Swanson and Wang 
recommend that studies in this field should focus on the know-how as it effects 
implementation and assimilation and the know-why as it effects adoption, as well 
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as the interplay between both forms of knowledge. Other case studies might 
examine how this know-why and know-how contrast according to both 
organizations and their various innovations. 
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